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; Abstract. 

/.This paper describes the use of cryptographic an- ' 
tbentication for controlling computer viruses. The 
objective is to protect against viruses infecting soft* 
ware distributions, updates and programs stored or 
executed on a system. The authentication deter- 
; mines the source and integrity of an executable, re- ' 
lying on the source to produce virus free software. 
. The scheme presented relies on a trusted (and verifi- 
" \ - .able where possible) device, the autheniieaior t used 
. to authenticate and update programs and convert 
programs between the various formats. To addition, 
. . each user's machine uses a similar device to perform 
. run-time checking. - 

1 Introduction 

Computer security has been the subject of research for a 
number of years. The research in this area concerned it- 
self with preventing unauthorized changes to programs and 
data [12, 14, 15, IS]. One type of attack that has been 
. studied is the so called Trojan Horse attack. More recently 
the computer virus, a special type of Trojan Horse, namely 
one that can propagate itself, has heightened concerns about 
computer security both in the computer science community 
and the public [3]. Current computer sy stems offer H mi led 
protection against attacks by computer viruses. These vi- 
ruses spread by working with the existing access control 
mechanisms infecting executable files. If left untreated, a vi- 
rus can spread to the transitive closure of all system objects 
thai are accessible by tbe users of the infected program(s) 
and are infectible. The success and rate of penetration are 
related to the design of the virus and such things as the num- 
ber and the utility / popularity of the programs currently 
infected and their availability. 

It is well known [1, 10, 19J that determining whether an 
executable has viral properties is hard. This is indepen- 
dent of whether the executable is stored on a disk, ROM, 
PLA or designed into a chip. However, determining if a 
virus has been added to an executable is simply detecting 
the modification of a file or message. Mauy techniques ex- 
ist for detecting the modification of data. Error detecting 
codesflC] are widely known and are used for this purpose. 



' However, while such codes may be sufficient for "random" 
and certain other types of errors, they are quite insufficient 
for protection against a determined adversary. Therefore, it 
is necessary that signatures be generated by strong crypto- 
. graphic techniques. 

Om view of software creation is similar to what 6ne ob- 
. serves in the manufacturing of drugs. Just as people depend 
on pharmaceutical companies to produce uncontaminated 7 
products, users depend on software vendors* products being . 
virus free.^ We assume that trustworthy software vendors 
, : have sufficiently clean environments that they can determine 
that their product, as released, is virus free. Our main goal 
is the protection of software from tampering during distri- 
bution and storage and execution. Consider software as if 
" -. it were a drug ; Our goal is to protect the product from the 
moment it leaves the "clean room" till it is consumed. Un^ 
like a drug, software is consumed many times and must be 
protected even after it has been "injected" into the body, 
.i.e. stored on disk in the user's system. 

We assume that the software produced by a vendor is 
. produced in a dean environment and is virus free. To protect •• 
software during distribution, storage and execution we: 

1. Distribute software, releases and updates, to users in 

. tamper proof "containers". The tamper proof nature " 
of these devices is provided by cryptographic authen- 
tication. 

2. Update software without introducing viruses into the 
new release. 

3. Authenticate software, both when fetched from disk 
and during execution. 

2 Previous Work 

Tne concept of a virus has received considerable attention 
since it was first introduced, both in the academic literature 
and the popular press. The use of cryptographic verification 
to check programs prior to and during execution was pro- 
posed in Popek and Kline [18], Davida and Livesey f5l and 
Davida and Matt [6, 7, 8]. 

Cryptography, as a means of protection against viruses 
appeared in Pomo and Grey [19, 20). There a mechanism 
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was proposed to sign executable load modules using a puby 
lie key cryptosystem [J l) t and check signatures as programs 
are loaded. Another approach suggested was to encrypt the 
entire executable. Cohen |4j presents another approach for 
checking executable as they are loaded. 

A scheme based on linear feedback shift registers (LFSR) 
for protecting executable during run- time appears in Joseph 
and AviZienis [13]. Their approach involves having the com- 
piler and loader generate a signed control flow graph (CFG) 
for a program using LFSRs and encrypting the result to 
form the program's "signature". At run time, the CFG is 
decrypted by a special device and the signatures checked as 
the program executes the instruction corresponding to the 
edges of the graph. Several open questions exist about their 
approach. 

1. Flow control change instructions are not included in 
the signatures. Can a virus be installed by modifying 
only these instructions? 

2. Is it possible to create a new version of an existing 
branch of a control flow graph that contains a virus? 
The signature generator used is LFSR based, and it 
is well known that LFSRs are vulnerable to known 

• plaintext attack [2, 17]. The authors attempt to pro- 
tect against this by encrypting the CFG and signa- 
. tures. However, when an interrupt occurres, the con- 
tents of the LFSR must be saved along with the pro- 
% " - ■ gram counter in order to restart the LFSR after the in- 
terrupt has been serviced. Unless the interrupt stack is 
encrypted, or a separate physically secure stack is used, 
enough information will be available to determine the ' 
polynomial used. Unless the CFG is referenced at each 
' . .interrupt return, the polynomial would have to be re- 
tained on a stack as well. The alternative to storing 
the LFSR at interrupt is to roll back to the beginning 
of the current CFG path on each interrupt. 
Once the program's polynomial is determined the sig- 
nature for all edges of the CFG can be determined. An 
edge can be selected for infection such that the edge's 
si^nalnrp. with the virus, is identical to the original. 

3. Consider the following attack: The Back Track At- 
tack 

(a) D 19- assemble the executable. 

(b) Add the virus to a load-module. 

(c) Assemble and link. The software generates new . 
CFG with primitive polynomials and signatures . 
and encrypts the new CFG. (Is this precluded by 
their remark about proper key management?) 

(d) The program is replaced with the new version. 

The general form of the Back Track ALlack is to back up 
from the executable, or come forward from source or load- 
modules, until the point where the encryption is performed. 
Then let program development tools (linker, assembler, etc) 
perform the encryption and replace the old version. All the 



designs mentioned [20, 19], and [13] appear to be susceptible, 
to this attack. • 

The Back Track method of vims insertion is diffictllt 
to stop unless either programs in aO their forms (source, 
load-modules, executable) are protected from their owners 
or the users of signature generating programs are authen- 
ticated. The user or system manager 1 can supply a key 
for use in the program authentication process but the key 
must identify the individual as well, Le. not be supplied to 
the signature generating program automatically. The act of 
generating a program signature must require the active user 
participation. This participation must authenticate the user 
and verify that the user knowingly requests (he program sig- 
nature creation. 

Having the authentication'generator as part of an on-line 
system as has been done in previous works is dangerous. It* 
is far easier to verify and protect a stand alone device. 

3 Software Distribution 

Our model of software distribution is the classical insecure 
communication channel [9], as in Figure 1. Vendors ship 
software, both full releases and updates, either directly to 
end users or to retailers. While undergoing development, 
or being processed by the authenticate, we assume that 
the software is protected. While in storage, at the vendor 
awaiting shipment or at the retailer, or in the system itself, 
it is in an insecure channel. : . V 

The scheme consists of performing the following: 

3 . The vendor generates signed software. 

2. The user is able to verify the signed software. 

. 3. The user installs (/ or customizes ) the software, pro- 
ducing a local executable module. 

4. The user creates a signed, block and overall, module. 

5. During execution, the user's machine checks the exe* 
cuting programs using a built in hardware authentica- 
tor. ' 

For stand-alone single-user systems, steps 2 thru 5 can be 
performed on a machine incorporating a hardware authenti- 
cator. In multi-user systems, on the other hand, steps 2 thru 
4 have to be done either on a separate dedicated authenti- 
cator system or, if the hardware authenticates unit is part 
of the computer system, during a special single-user session. 

Our choice of hardware authenticator devices is moti- 
vated by the following: 

1. The Vendor Level 

Given the nature of the vendor's environment it is 
"possible" to authenticate a product using strictly soft- 
ware. However, confidence in such a procedure will not 
be high. 

'In a multi-user system many of the procedures described in Ibis 
paper would be performed by a system manager. 
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Figure I: Software Distribution 



.2. The User Level 

At the user level it is even more important, if not 
absolutely necessary, to implement authentication in 
hardware. The users of a software product may be 
considerably less sophisticated than the vendor. 

Hardware is in general more tamper resistant than software. 
Hardware authentication devices are less susceptible to soft- 
ware tampering than software authentication procedures. 
• \ ' A purely software authentication system must rely on 
. considerably more complex protocols to verify the authen- 
ticity of a software product. A cold start must be em- 
ployed and the normal system disk(s) must be removed. The 
disks/diskettes used in the authentication process are more 
vulnerable to tampering than a dedicated unit, and the ini- .. 
tialization process is more complex than most ordinary users - 
can be expected to handle. 



Our solution utilizes public key cryptosystems for distri- 
• bution of software between vendors and users; if you will, 
between a pharmaceutical house and the individual. Soft- 
ware retailers, like pharmacists and others with access to the 
product, arc not trusted. The vendor signs the software dis- 
tribution or update using a private key. The corresponding 
public key is available to all by means of a public directory. 
The user or system manager authenticates the software by 
using the vendor's public key. 

Cryptosystems are used to authenticate software in the 
user's possession. The user must first authenticate the ven- 
dor's software and then "seal" the result by creating his/her 
own authenticator for it. For software systems that need to 
be configured (or customized) at the user site, this step is es- 
sential if the authentication of an installed software module 
is to be carried out without going through a TttnstaUation '• 
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■ process and authentication of the original Wconfourrdprod- 
net. • - ■ * ■ . 

The cryptosystera used to generate the user's seal may be 
a conventional icryptosyslem or a public key cryptosystcm. 
If a public key system is chosen it may well be the same 
system. used by the vendor. 

To continue with the pharmaceutical analogy, the con-' 
sumer takes the drug home and checks the "tamper proof" 
seal(s). If the seals are in an acceptable state, the drug is 
removed, from the vendor's package and may then be further 
. protected, as when parents keep drugs in child-proof cabinets 
or containers. The product may be placed in a medicine cab- 
inet (software kept off-line) or "injected" immediately into 
. . :the system (placed on-line). 

r The creation of signed software distributions by the ven- 
dor is performed by the vendor's authenticator device. The 
additional signing of the installed software is carried out by. 
the user's authenticator. 

The vendor's authenticator performs the following steps 
for a software release:. 

1. Read the vendor's private key. 

2. Generate the signature for the release including the fol- 
lowing pertinent data: program name, serial number, 
version number and date of release. 

The user's authenticator perforins the following steps for 
a software release:. 

1. Store the vendor's public key and the user's key. 

2. Verify that the signature for the release is correct and 

. display pertinent data: program name, serial number, . 
version number, date of release, and so on. 

.3. Configure the program, if necessary. ' 

4. Create a block and overall signed program. 

It is the block-signed version that is loaded into the system. 

The block signature scheme involves generating a signa- 
ture for every page / segment (independently loaded block) ' 
along with a new overall signature. The block signature 
method utilizes the starting logical address of the block and 
a system wide program identification / version number, in 
' the signature generation. The logical address is used to pre- ' 
vent any re-ordering of the blocks in the program. The use of 
the program identification/ version number prevents substi- 
tution of signed blocks from another program or a different 
version of the same program 3 . 

The signed version is checked at run time by the authen- 
ticator unit located on the user's machine, see Section 5. 



*Aa an Alternative to program identification numbers, different keys 
could be used to sign each new version of each program but the number 
of keys becomes too large. Another approach is to use fewer keys and 
incorporate a program / version identifier into the key. 



3.1 Updates 

Performing an update requires the combination of the most 
recent complete release of the software available to the user, 
with one or more updates. Updates arc distributed, as op- 
posed to sending out new releases to reduce costs. If the 
amount of information necessary to patch the software is 
significantly less than would be contained in a new release, 
then an update is chosen. 
. . To perform an -update the vendor's authenticator creates 
a signed update by performing the following steps: ** 

1. Read the vendor's private key. 

2; Generate a signature for the new complete release, in^ 
eluding the following pertinent data: program name, 
serial number, version number and date of release. ■ 

3. Generate a signature for the updates only intruding the 
following pertinent data: program name, serial nun>.' 
ber, version number and date of release. 

4. Send the signed update for the new complete release - 
to the users. In addition, the signature for the new 
complete release is sent. (The complete release is not 
sent.) 

The user combines the update with the most recent complete 
. release ( see Figure 2 ) as follows: 

1. Verify the vendor supplied update signature; . 

2. Perform the update creating the new release. 

3. Verify the new release signature. ' 

4. Create a new block and overall signed executable pro- 
gram. 



4 Authenticator Design 

Ideally, the authenticator is so simple and its users suffi- 
ciently sophisticated that they can verify the implementation 
of the authenticator. As a practical matter, the supplier of - 
the authenticator or some "independent" testing laboratory 
would perform the verification. 

How the design is implemented, the technology used, is 
critical not only to verification but to protecting the device 
against "hardware" viruses [10] as well. Viruses can be im- 
planted into ROM chips, PL As or coded into complex chips 
during the design process. Simple components make reverse 
engineering feasible and helps the detection of tempering. 
The use of simple components offers other advantages: 

1. The complexity of the chips will be low. 

2. Stock items can be used, making it more difficult for 
a manufacturer or supplier to infect chips destined for 
the authenticator. 
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Figure 2: Software Updates by & User.. 



3. Multiple chips should be necessary to perform a sin- . 
glc function, for example a register. This is intended 
to force the virus to be spread across devices. If the 
chips used to perform the function are from different 
manufacturers the difficulty of implanting a virus is 
increased. . 

A. Older chips can be utilized. Items can be selected that 
were manufactured years apart. More significantly, 
chips can be used that are older than the virus concept. 

When a user operates an authenticate^ he/she along 
with the authenticator device. provides a guarantee of the 
authenticity and integrity of the software. The authentica 
tor creates a signed version that could include the vendor'* 
signature. 

This provides software users with more security than 
what is often available with drugs. Many drugs are dis- 
tributed to pharmacists in Urge quantities, and though the 



container may have a seal when it arrives at the pharma- 
cist, the seal is broken for the first customer and it is the 
pharmacist's responsibility to protect it from that point on- 
ward. Signing the result provides even more protection than 
locking the unsealed container in a safe. 

Individual users may execute their own un-authenticated 
programs. In multi-user systems, users who wish to protect 
their own private programs against viruses may ask a system 
manager to have their programs signed. For stand-alone 
systems, this is obviously simple to do. 

5 "Invivo" Protection 

Even after the vendor's signature has been validated soft- 
ware is still vulnerable. The threat is not lessened by storing 
it in the user's machine. Since we consider the user's system : 
to be a hostile environment, wc must authenticate the code 
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. that wc run .as often as feasible. This is the function of the 
machine's authenticator. 

' The key stored in the aut hen li cation unit must be pro- 
tected, both from (read 3 ) and write access. In our design 
the (secret 3 ) key is stored in the authentication unit directly. • 
Even the operating system kernel, while using the unit to au- 
thenticate programs, does not have access to the key. The 
authentication unit must have its own externa] input/output 
channel for initialization. 

Two main difficulties must be surmounted. Making sure 
that the operating system utilizes the authentication unit 
• properly, and how often and how much of a program should 
be checked. We note in passing that the operating system 
itself may be checked as described above. This may even 
, be done using "surprise inspections" techniques using exter- 
nally generated schedules. Special architectural support is 
needed. 

5.1 When to Check 

A program can be checked in is entirety when it is loaded into 
the system and in addition, periodically by some background 
task. A complete check when the program is executed may 
not be feasible. Some systems use a demand load format 
which results in pages or segments being loaded from the 
executable only as needed. If, on the other hand, the au- 
thenticator unit is sufficiently fast and all of the program is 
brought into memory,(possibly with some of it being paged 
out into the page / spool area on disk), then it is feasible to 
check the entire program before executing it. 

Even a running program (a process) is at risk. When- 
ever a process does not have control of the processor, it is 
vulnerable to attack*. Pages, segments, entire programs are 
moved by the operating system to and from the paging /. 
swapping area on disk, While in the paging / swapping 
area this information is vulnerable to tampering. To protect 
against this, all data moving into main memory from the 
paging / swapping area, should be authenticated requiring ' . . 
appropriate architectural support. 

The authentication may result in adjustments to the op- 
erating system's memory manager. If the cost of moving 
information between disk and main memory is significant, 
it may be necessary to decrease the number of concurrently 
executing programs or keep processes swapped out longer. 

The importance of providing this level of protection should 
not.be underestimated. Certain operating systems, (for ex- 
ample UNIX systems), allow for a program to be loaded into 
the page / swap area on first execution and have the text 
portion remain there, even after all current executions of it 
have finished. This copy is the "source" for all subsequent 
executions. Programs of this type are read, at most, once 
from the copy in the file system between system boots. 

In addition to attacks mounted against the process by 
using the page / swap area, it is possible to infect the process 
by changing the information currently in memory. Whenever 

3 If a. conventional system is used. 

*ln the following we assume a uni-processor system. 
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H ' 

a context switch or interrupt occurs another program runs 
and all suspended programs are at some risk. This can be 
detected if instructions can be checked concurrently with 
their execution. ■ 



The Granularity 



5.2 What to Check: 
Problem 

In the previous section we proposed that the authenticator 
signs the entire executable and units of pages and / or seg- 
ments. We now propose that individual instructions can be 
authenticated as the CPU executes them. This authentica- 
tion can be performed as part of the flow of control as in [13], 
but with all instructions signed, as in Figure 3. Instruction 
checking is performed in parallel with the execution cycle 
and generates a signature fault if it fails. The signature 
mechanism must prohibit relocation. 

6 Remarks 

The advantages of the proposed system are; 
I. Increased confidence in software security. 
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2. Simple checking mechanisms based on hardware which 
arc more tamper resistant. 

3. Updates are easily allowed. 

4. Allows for variable granularity of checking during ex- 
ecution. 

5. Separation of checking hardware from the system hard- 
ware. 
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